The present invention relates to the field of telephony, and more particularly to Internet Protocol (IP) based telephony.
Voice over Internet Protocol (VoIP) refers to the technology to make telephone calls and send faxes over IP-based data networks with a suitable quality of service (QoS) and superior cost/benefit. The main justifications for development of VoIP can be summarized as follows:
Cost reductionxe2x80x94VoIP technologies can provide substantial savings in long distance telephone costs, which is extremely important to most companies, particularly those with international markets.
Simplificationxe2x80x94An integrated voice/data network allows more standardization and reduces total equipment needs.
Consolidationxe2x80x94The ability to eliminate points of failure, consolidate accounting systems and combine operations, providing for more efficient operations.
Advanced Applicationsxe2x80x94The long run benefits of VoIP include support for multimedia and multi-service applications, for which current telephone systems are not equipped.
Growth in the VoIP market is expected to be considerable over the near future. However, there remain many challenges facing developers of VoIP equipment, both in terms of voice quality, latency and packet loss as well as call control and system management. The primary challenges are: the severe restrictions on acquisition and use of registered IP version 4 addresses, the resulting need to use Network Address Translation (NAT) and related technologies, the limitations of existing firewall technologies, and the application layer requirements of VoIP protocols such as MEGACO, RTP, and RTCP.
The American Registry for Internet Numbers (ARIN) has placed severe restrictions on the allocation of routable, public IP addresses due to the popular growth on the Internet, and the rapid depletion of remaining available addresses. In order to conserve address space, ARIN strongly encourages end users to utilize NAT technology to conserve address space. The most common implementation of NAT is NAPT, or Network Address Port Translation. This allows a single public IP address to be used to support thousands of hosts using private (RFC 1918) addresses. The major problem with NAT is that it only modifies the source IP address and port information in the IP header, and not anywhere in the payload. A typical VoIP protocol uses the IP and port information of the host in the payload for caller identification and call routing. Thus, when a Media Gateway Controller (MGC) or Trunking Gateway (TG) receives communication from an end-node with conflicting information, considerable problems may result. Note that as used herein, the term xe2x80x9cTrunking Gatewayxe2x80x9d refers to any device that simultaneously receives multiple analog inputs and encodes the signal into multiple corresponding IP data streams. A Trunking Gateway may also perform the reverse function of simultaneously taking multiple signals encoded into a multiple IP data streams and converting it to multiple corresponding analog signals.
The NAT process is also dynamic, and so a host will be associated with a specific port number only during the session in progress. The next session will almost assuredly be over a different port. This problem is exacerbated by the fact that two end nodes that need to communicate directly may be using the same private IP address.
Another issue relates to the firewall. Firewalls are typically designed to protect internal networks from external networks, and generally need to be aware of when sessions open and close so that the network does not remain vulnerable. Most protocols used on the Internet are TCP based, and thus the firewall can determine when sessions are opened and closed based on SYN and FIN messages. Unfortunately, most VoIP protocols are UDP based, and therefore do not utilize SYN and FIN messages that the firewall can detect. Complicating matters further, VoIP protocols often use pairs of ports for communication, initiated from both the inside and outside of the network. Firewalls tend to support single port communication only initiated from the inside. Additionally, triangulated communications between IP telephones present a particular problem, referred to as the xe2x80x9ctriangle problemxe2x80x9d, described below.
The traditional solution to an upper-layer protocol that does not work with NAT is an Application Level Gateway (ALG). An ALG acts as a proxy by modifying the IP address and header information in the payload of the various protocols being used (MEGACO, RTP, RTCP) to match the information replaced by the standard NAT function. Additionally, the ALG typically xe2x80x9cnegotiatesxe2x80x9d with the NAT gateway to reserve any specific port or port ranges necessary to support the protocols. This has been done for a variety of protocols such as ICMP and FTP, and lately H.323 and SIP (two earlier VoIP standards), and solves the basic problem of public IP to private IP communication. What are not addressed are the more complex interactions such as triangulated routing shown in FIG. 1. As FIG. 1 shows, a Media Gateway Controller (MGC) 50 is coupled to Application Level Gateway 70. The AGL 70 is coupled to two IP telephones 20A and 20B, respectively. The IP telephones 20 are also coupled to one another directly. If IP telephone 20A contacts Media Gateway Controller 50 for Call Setup through ALG 70, the MGC 50 contacts IP telephone 20B (on the same network as IP telephone 20A) through ALG 70, and IP telephone 20B attempts to contact IP telephone 20A on the local network, the ALG 70 between IP telephones 20A and 20B must be sophisticated enough to only correct the private address information when appropriate.
The above problem may become very complex considering that the ALG 70 must maintain a local table of all internal hosts (IP telephones 20), examine the call destination address information coming from the MGC 50, and decide whether or not to modify it when routing it to the internal hosts 20. The alternative would be to route all traffic through the ALG 70 regardless of whether the destination is in the internal network, perform the ALG function, then the NAT function twice, then the ALG function again, and then route it back out the same interface. This convoluted process would be required for every single packet, introducing substantial inefficiencies to the system.
Therefore, improved systems and methods for IP telephony are desired.
The present invention includes various embodiments of a system and method for performing IP telephony. In one embodiment, the system may include a network, at least one Media Gateway, such as an IP telephone or Trunking Gateway, a Service Gateway, operable to couple to the Media Gateway through the network, and a Media Gateway Controller, operable to couple to the Service Gateway and the at least one Media Gateway through the network.
In one embodiment, the Media Gateway may be an IP (Internet Protocol) telephone. The IP telephone may first be activated. In response, the Service Gateway may negotiate a client DHCP lease with the IP telephone. The Service Gateway may use an identifier, e.g., a vendor ID, of the IP telephone to determine a range of port numbers to assign to the IP telephone. In other words, the Service Gateway may receive the identifier from the IP telephone, and if the identifier is valid, assign the port range to the IP telephone. In one embodiment, the Service Gateway may receive a MAC ID of the IP telephone in addition to the vendor ID. The Service Gateway may determine if the MAC ID for the IP telephone is valid, and if the MAC ID is determined to be valid, then determine if the identifier is valid.
The range of port numbers may include one or more port numbers which are not reserved for use by other IP protocols. The client DHCP lease negotiations may include the IP telephone issuing a DHCP discover message to the Service Gateway, which may then issue a DHCP offer to the IP telephone if the identifier is determined to be valid. The DHCP offer may include DHCP lease information based on the validated identifier, such as the range of port numbers and information indicating operational software for the IP telephone. The Service Gateway may store the DHCP lease information. The IP telephone may store the DHCP lease information, and enable DHCP settings included in the DHCP lease information.
The Service Gateway and the IP telephone may then operate to initialize the IP telephone. In one embodiment, the IP telephone may be initialized by executing the indicated operational software to enable IP communications. In one embodiment, the IP telephone may issue a request for the operational software, after which the Service Gateway may provide the operational software to the IP telephone, which may then execute the provided operational software to enable IP communications. In one embodiment, the IP telephone may issue a read request to a file transfer server, e.g., a Trivial File Transfer Protocol (TFTP) Server, for the operational software, which may then provide the operation software to the IP telephone. In one embodiment, the file transfer server may be included in the Service Gateway.
In one embodiment, the IP telephone may be registered by the system, e.g., by the Media Gateway Controller, prior to the Call Setup process. For example, the IP telephone may send a public IP address of the IP telephone to the Media Gateway Controller, which may receive and store the public IP address of the IP telephone. In one embodiment, the IP telephone may also send a private IP address of the IP telephone to the Media Gateway Controller, which may receive and store the private IP address of the IP telephone. The Media Gateway Controller may be operable to use the public IP address and the port range to determine the private IP address, for example, by using look-up tables.
After the registration, IP communications may be performed using the IP telephone, using one or more ports in the range of assigned ports. For example, the Service Gateway may mediate IP communications between the IP telephone and an IP device, such as another IP telephone, or a Trunking Gateway, among others.
In one embodiment, performing IP communications using the IP telephone may include the Service Gateway receiving a data packet from the IP telephone, including a private source IP address, a source port number in the assigned range of port numbers, and destination information associated with an IP device. The Service Gateway may then perform a Network Address Persistent Port Translation (NAPPT) on the data packet, and send the data packet to the IP device. Performing NAPPT on the data packet may include changing the private source IP address to a public source IP address while leaving the source port number unchanged, and where the public source IP address and the source port number may be used to uniquely identify the IP telephone.
In another embodiment, performing IP communications using the IP telephone may include the Service Gateway receiving a data packet from the IP device, including a public destination IP address, a destination port number in the assigned range of port numbers, and source information, where the public destination IP address and the destination port number may be used to uniquely identify the IP telephone. The Service Gateway may then perform a Network Address Persistent Port Translation (NAPPT) on the data packet, and send the data packet to the IP telephone. Performing NAPPT on the data packet received from the destination may include using the public destination IP address and the destination port number to uniquely identify the IP telephone, and changing the public destination IP address to a private source IP address of the IP telephone while leaving the destination port number unchanged.
In one embodiment, various embodiments of the methods described above may be included in a memory medium. In another embodiment, various embodiments of the methods described above may be included in a plurality of memory mediums, which may include one or more of an IP telephone memory medium storing IP telephone program instructions, a Service Gateway memory medium storing Service Gateway program instructions, and a Media Gateway Controller memory medium storing Media Gateway Controller program instructions, where the program instructions included in the plurality of memory mediums may be executable to perform various embodiments of the methods described above.
In one embodiment, the system may include the network, two or more Media Gateways coupled through the network, as well as the Media Gateway Controller, coupled to the Media Gateways through the network.
In one embodiment, the Media Gateway Controller may receive a Call Setup request, where the Call Setup request may include a source IP address and a destination telephone number. The Media Gateway Controller may select a first Media Gateway based on the source IP address, and a second Media Gateway based on the destination telephone number.
The Media Gateway Controller may compare a public IP address of the first Media Gateway to a public IP address of the second Media Gateway, and if the public IP address of the first Media Gateway is the same as the public IP address of the second Media Gateway, may select a private IP address of the first Media Gateway and a private IP address of the second Media Gateway for Call Setup. Note that if the public IP addresses of the Media Gateways are the same, then they are internal to the system. If the public IP address of the first Media Gateway is not the same as the public IP address of the second Media Gateway, the Media Gateway Controller may select the public IP address of the first Media Gateway and the public IP address of the second Media Gateway for Call Setup. This describes a case when a call session is between an internal IP telephone (e.g., the first Media Gateway), and an external device, such as a telephone, communicating through a Trunking Gateway (e.g., the second Media Gateway). Thus, in one embodiment, the first Media Gateway and the second Media Gateway may each include one of an IP telephone or a Trunking Gateway, where the Trunking Gateway includes an interface to the Public Switched Telephone Network (PSTN).
In one embodiment, the Media Gateway Controller may send the selected IP address of the first Media Gateway to the second Media Gateway, and send the selected IP address of the second Media Gateway to the first Media Gateway. The first Media Gateway may then send data to the second Media Gateway using the selected IP address of the second Media Gateway, and the second Media Gateway may send data to the first Media Gateway using the selected IP address of the first Media Gateway.
In one embodiment, the Media Gateway Controller may register the first and second Media Gateways prior to receiving the Call Setup request, as described above. In one embodiment, registering the Media Gateways may include receiving and storing the public IP address of each Media Gateway. In another embodiment, registering the Media Gateways may also include receiving and storing the private IP address of each Media Gateway.
Thus, various embodiments of the system and method described above may distinguish between call sessions involving two internal IP telephones, and call sessions between an internal IP telephone and a Trunking Gateway, for example, interfacing with an external device, such as an external telephone.